Group friendly fire: warn on Harmony conflicts (4/4, part of #277) - #304

Nice reuse of the existing StratumHarmonyVisibility walk rather than a new scanner, and CollectOwners mirrors CountOwners cleanly. One additive commit, sources only, compiles against #300 alone.

One thing I think bites in practice. The guard at StratumHarmonyVisibility.cs:99 only walks when BlockGroupDamage is already true, and the single call site is OnBeginRunGame (ServerSystemStratum.cs:109). AllowGroupDamage defaults to true, so on a stock server the method returns at line 102 and nothing is checked, and an admin who later runs /friendlyfire off gets the protection but never the warning, which is the case it exists for. It also means the smoke run in the body only exercised the early return. Calling it from StratumFriendlyFireSystem.Apply would cover boot, the command and /stratum reload in one place.

Two smaller ones. Line 87 watches ServerMain.CreateExplosion and lines 88-91 the interaction and projectile seams, which only become Stratum seams once #302 and #303 land; on this base the entry asks an admin to verify a block that never happens. And line 123 removes "(unknown)" right after line 142 produced it, so an unattributed patch is dropped, and when it is the only one on a watched method the warning is skipped outright. Keeping "(unknown)" in the message is strictly more useful.

Line 74 says "when the toggle is on we name the mod", line 95 says the opposite. The code warns when friendly fire is off. Which wording do you want to keep?

Switching to a change request: as written the walk never runs on a default server and never re-runs on /friendlyfire off, so the warning cannot reach the case it was written for. Calling it from StratumFriendlyFireSystem.Apply covers boot, the command and reload. The watchlist entries and the (unknown) owner are secondary.

Thanks, two of the three are settled. StratumHarmonyVisibility.cs:74 now matches the guard at 99, and dropping the Remove call means an unattributed patch survives the count check at 123 and reaches the message at 128.

The call site move is only half of it. Apply at StratumFriendlyFireSystem.cs:45 covers /friendlyfire (104) and /stratum reload (CmdStratum.cs:216), both after mods are loaded. Boot went the other way. The constructor's Apply at 27 runs from ServerSystemCommands.OnBeginConfiguration, which ServerMain calls at 1337, and mods install their Harmony patches later: OnLoadAssets at 1340 runs the Pre and Start phases, OnBeginModsAndConfigReady at 1346 runs StartServerSide. So GetAllPatchedMethods is empty when the boot walk runs, and a server starting with AllowGroupDamage false plus a conflicting mod warns nothing, which the OnBeginRunGame call you removed did catch. Keeping both call sites covers all three paths.

Still open from the first pass: ServerMain.CreateExplosion at 87, while StratumFriendlyFireConfig.cs:9 on this base says explosions are not covered by the toggle. And the body still describes the OnBeginRunGame call and the smoke run that went through it, so it needs a refresh whichever way the call site lands.

That closes it. ServerSystemStratum.cs:109 runs WarnFriendlyFireConflicts from OnBeginRunGame again, after OnLoadAssets and StartServerSide have let mods patch, and Apply at StratumFriendlyFireSystem.cs:45 still covers /friendlyfire and /stratum reload, so all three paths see the real patch list. CreateExplosion is out of the watchlist for this base, and the body describes the two call sites as they are. Approving.